1. Field of the Disclosure
This disclosure relates generally to computer systems that implement transactional memory, and more specifically to a system and methods for synchronizing transactions using a new type of transaction condition variable for which transaction isolation properties are relaxed.
2. Description of the Related Art
Transactional memory is a promising technology to ease programming of multiprocessor systems. With transactional memory, a thread can execute a block of code as a transaction, which may either commit (in which case its effects become visible to other threads) or abort (in which case its effects are discarded). A transactional memory system manages the transactions, ensuring that transactions that commit are isolated (i.e. that each transaction appears as though it were executed without any operations of other transactions being interleaved with its own) and that the transactions appear to be executed in a consistent order (i.e. the transaction order). Thus, a transaction sees the effects of those transactions that precede it in the transaction order, and no transaction sees partial effects of any other transaction.
The isolation property of transactions can greatly simplify concurrent programming. For example, a programmer can consider each transaction separately, rather than having to consider all possible interleavings of its operations with the operations of other transactions. However, isolation can also limit the applicability of transactions. For example, isolated transactions are incompatible with some common synchronization mechanisms, such as barriers and ordinary condition variables. More generally, isolation disallows programming idioms that require communication among transactions while they are active (i.e. not yet committed or aborted).
Locks (which are often used to provide isolation for critical regions of code), and semaphores, (which are sometimes used to order events, e.g., such as the execution of various critical regions), are among the earliest synchronization mechanisms in concurrent programming. Experience has shown that it is not sufficient to have two independent mechanisms. Rather, it is desirable to have structured mechanisms that integrate them, such as monitors (which may employ condition variables). However, current mechanisms do not provide condition synchronization with transactions, that is, a mechanism that integrates transactions and the ordering of events in a manner analogous to condition variables.
Existing proposals for providing such synchronization include (i) conditional critical region (CCR) style transactions (which allow execution of a transaction only if a particular condition is satisfied, and in which the execution of the transaction is delayed until the condition is true); (ii) a retry construct (which aborts a transaction that calls retry, and re-executes it only when something in that transaction's read or write set is modified); and (iii) a wait construct or ordinary condition variable (which “punctuates”, i.e., commits, the waiting transaction and begins a new transaction for the waiting thread on receipt of a notification from a concurrent transaction). However, none of these proposals allow synchronous communication (e.g., n-way rendezvous operations) between concurrent transactions.